Loading data onto an electronic device

ABSTRACT

A method of protecting an electronic device from unauthorized reprogramming, the electronic device comprising a data memory and a key memory, the method comprising loading into the key memory a predetermined public key of a cryptographic public key mechanism for verifying subsequent data items to be loaded into the data memory, the subsequent data items being signed with a corresponding private key; characterized in that the method further comprises setting a permanent identifier in the electronic device, the permanent identifier including an identifier identifying an entity authorized to reprogram the electronic device and an indicator identifying a selected one of a number of categories of public keys.

This patent application claims the benefit of priority from U.S.Provisional Patent Application Ser. No. 60/412,374 filed on Sep. 20,2002, and U.S. Provisional Patent Application Ser. No. 60/414,129 filedon Sep. 27, 2002. This application incorporates by reference the entiredisclosure of U.S. Provisional Patent Application Ser. Nos. 60/412,374and 60/414,129.

This invention relates to the loading of data, in particular software,into electronic devices. More particularly, the invention relates to theloading of data into an electronic device comprising a data memory forstoring data items and a key memory for storing at least onecryptographic key of a cryptographic public key mechanism. The inventionfurther relates to the protection of such an electronic device fromunauthorised reprogramming.

Many modern electronic devices, such as mobile terminals, comprisememory for loading software and/or data for use with the electronicdevice. Typically, a manufacturer of such electronic devices deliversthe device with or without some preinstalled software and/or data to acustomer who further customises the electronic device prior todelivering the device to an end-user.

Consequently, during production of the electronic device in a factory,software and/or data is loaded into the device, such as test software,pre-installed software to be delivered with the device, or the like.Furthermore, after production of the electronic device, further softwareand/or data is loaded by the customer, such as customer-specificsoftware, e.g. for providing customer-specific services, etc.

Several methods to load software (SW) into a programmable device areknown. However, existing methods have been designed to deal with securesoftware handling under the assumption that the producer of theelectronic device, e.g. a central processing unit of some electronicequipment, coincides with the producer of the final equipment, or thatthis unit is a standard component. If different manufacturers ofelectronic equipment buy the processing unit from a device manufacturer,they typically each have to load SW in their respective final equipment.An example of such a scenario is the production of a mobile telephoneplatform, e.g. a chipset, which is sold to a plurality of manufacturersof mobile phones, PDAs, or the like. In such a scenario, eachend-product manufacturer should be prevented from loading SW of anotherend-product manufacturer into the equipment.

Throughout this document, the term customer comprises any entity whichreceives the produced electronic device. Typically, a customer isanother enterprise or company which customises the electronic device,incorporates it into other electronic equipment, and/or sells it viacorresponding distribution channels to end-users. For example, theelectronic device may be a board to be incorporated into a mobile phoneby a phone manufacturer. In this example, the customer of the electronicdevice is the phone manufacturer.

In the following the electronic device delivered to the customer fromthe factory will be referred to as the product, in contrast to theelectronic device during production in the factory.

U.S. Pat. No. 6,167,521 discloses a method of loading new code into alogical subregion of a device which is controlled by an authority.According to this prior art method, the authority prepares a messagecomprising the new code and certain parameters which specifyrequirements on the execution environment for the new code to run. Theauthority sends the generated message to the device which, upon receiptof the message, performs an authentication of the authority and verifieswhether the parameters are valid for the current execution environment.If yes, the device loads the received new code into the correspondinglogical subregion.

However, the above prior art method does not address the problem that,for security reasons, when producing electronic devices it is desired toseparate production and subsequent customer-specific customisation. Forexample, the manufacturer of a board to be incorporated into a mobilephone may wish to limit the possibilities of a customer of that board,e.g. a phone manufacturer, to customise the product, i.e. the board.Furthermore, a customer may not wish any customer-specific productsoftware which the customer may have loaded into the device, i.e. theboard, to be available for other parties, e.g. other phone manufacturerswhich are customers of the manufacturer of the board.

Hence, the tools used for loading software in the factory should notwork with the product once it has left the factory and, vice versa, thetools used in connection with the product outside the factory should notbe used during production inside the factory.

It is known to secure such loading tools by physical hardware devices,such as hardlocks, smart cards, dongles, or the like. According to suchprior art solutions, a loading tool only allows operation, if acorresponding external device is connected to the loading tool, e.g. asmart card inserted in or a dongle connected to a predetermined port ofthe tool, etc.

However, the use of such physical devices has a number of problems: Thehandling and control of such devices generate a lot of overhead, as theyhave to be inserted and removed from the loading tools, stored in asecure place, etc. Furthermore, these devices are typically small andmay, therefore, easily get lost or even stolen, thereby posing asecurity risk. Furthermore, modern electronic devices often have rathershort life cycles. Consequently, a considerable number of differentversions of electronic equipment and/or the corresponding softwareand/or the corresponding loading tools may exist, in many cases evensimultaneously. Hence, as the tools get more complicated they may dependon different versions of the physical devices, thereby increasing thecomplexity of version handling and maintenance of the loading tools andthe physical devices.

Hence, it is an object of the present invention to provide a secureloading of data into an electronic device during different stages of thelife cycle of the device.

According to a first aspect of the invention, the above and otherobjects are achieved by a method of loading data into an electronicdevice comprising a data memory for storing data items and a key memoryfor storing at least one cryptographic key of a cryptographic public keymechanism, the method comprising

-   -   loading a factory public key into the key memory;    -   loading factory software signed with a factory private key        corresponding to the factory public key into the data memory;        where the method is characterised in further comprising    -   loading into the key memory a product public key different from        the factory public key for verifying subsequent data items to be        loaded into the data memory after delivering the electronic        device to a customer, the subsequent data items being signed        with a corresponding product private key; and    -   disabling the factory public key prior to delivering the        electronic device to the customer.

Consequently, a division between tools used in the factory and the toolsused with the product outside the factory is achieved by using a specialfactory cryptographic key and a product cryptographic key. All softwareloaded in the factory is signed with a corresponding factory private keyand all software loaded into the electronic device outside the factoryis signed with a product private key. According to the invention, thefactory public key is disabled at the end of the production, therebyensuring that factory software signed with the factory private keycannot be loaded into the product outside the factory any longer.Likewise, any software signed with the product private key will berejected during production in the factory.

It is an advantage of the invention that the use of different keys forproduction of an electronic device and for the resulting productelectronic device ensures that production software can only be loadedduring production and product software can only be loaded into thefinished product. Consequently, the signed software used in productiondoes not need to be protected further, since it cannot be used outsidethe factory, thereby greatly simplifying the handling and control of theproduction software in the factory.

It is a further advantage of the invention that it provides a simple keystructure, thereby avoiding the need of maintaining and storing acomplicated key structure in the electronic device. This is especiallyadvantageous when the electronic device has limited storage and/orprocessing resources, as is the case for mobile terminals and the like.

When the factory keys or the product keys are indicative of apredetermined entity, e.g. a manufacturer, it is ensured that one entitycannot load software/data into an electronic device related to anotherentity, e.g. another manufacturer's device.

When the method further comprises the step of setting a protectableidentifier in the electronic device indicative of a completion of aproduction process, a mechanism is provided for securely determiningwhether a given device has completed a predetermined stage of theproduction process. For example, setting the protectable identifier mayindicate the end of the production process in the factory. Since theidentifier is protectable, i.e. can be permanently set, it can beensured that the device does not re-enter the factory process once ithas left it. Preferably, the protectable identifier identifies thecustomer, thereby ensuring that a customer cannot load anothercustomer's software/data, even if the cryptographic keys have beenmodified.

In a preferred embodiment, the step of loading the factory public keycomprises the steps of

-   -   detecting whether the protectable identifier is set;    -   if the protectable identifier is set, aborting the step of        loading the factory public key; otherwise loading the factory        public key.

It is an advantage that the tools used during the factory process whichsign any data to be loaded into the device with the factory private keycan only be used during the production process. Once the factory publickey is disabled in the device and the protectable identifier is set, are-loading of the factory public key is prevented, thereby increasingthe security of the method. Hence, it is an advantage that theprotectable identifier protects against removal of keys fromnon-volatile memory of the electronic device.

In a further preferred embodiment, the step of loading the productpublic key comprises the steps of

-   -   detecting whether the protectable identifier is set;    -   if the protectable identifier is set, loading the product public        key; otherwise aborting the step of loading the product public        key.        Hence, the product public key cannot be loaded before completion        of the production process as indicated by setting of the        protectable identifier, thereby preventing the use of        post-production tools during the production process. By        enforcing a strict division between production tools and        post-production tools, the risk of misuse or erroneous use of        tools is further reduced.

Alternatively, the protectable identifier may be loaded at other stagesof the production process, for example as an initial step of the processbefore loading the factory public key, or as a final step afterexchanging the factory public key with the product public key, or as anintermediate step after loading the factory public key but beforeloading any factory software, or at another suitable stage of theproduction process.

For the purpose of the present description, the term protectableidentifier comprises any identifier which may be set in the device andwhich may be protected against deletion and alteration. Hence, theprotectable identifier cannot—with reasonable effort—be changed orerased, once it is set and protected. Preferably, the identifieruniquely identifies the device. Examples of such a protectableidentifier include but are not limited to fuses burnt electrically, bymeans of a laser, or the like, charge memory, encapsulated permanentcapacitors, one-time-programmable (OTP) memory, etc., or a combinationthereof. In one embodiment, the protectable identifier may be related tothe product public key. For example, the product public key may bestored in OTP memory, thereby functioning both as the product public keyand the protectable identifier. Hence, an increased security is achievedby storing a public key into the key memory, e.g. flash memory,protected by a hardware mechanism, e.g. in the central chipset

In a preferred embodiment the electronic device is a mobile telephonehaving associated with it an International Mobile Equipment Identity;and the protectable identifier comprises the International MobileEquipment Identity and a further identifier stored in a one timeprogrammable arrangement. Hence a high level of security is provided andthe device is uniquely identified. Furthermore, the protectableidentifier (or part of the protectable identifier) stored in the OTPmemory may have a small size, e.g. 64 bits or less, thereby reducing thecost for the required OTP memory.

It is an advantage of the invention that the factory private key is onlyknown to the manufacturer of the electronic device, thereby ensuringthat other manufacturers cannot load their software into these devices.

The factory public key may be disabled by removing the key from memory,e.g. by setting all corresponding bits to zero or by overwriting it withthe product public key; it may be disabled by corrupting it, e.g. byaltering one or more bits of the stored key, or it may be disabled inany other suitable way, thereby preventing its subsequent use forverifying signed data items. Preferably, the factory public key ispermanently disabled, i.e. making it computationally infeasible toreconstruct the key, thereby increasing the security of the method. Inone embodiment, both the factory public key and the product public keyare stored in the beginning of the factory process, and the factorypublic key is disabled at the end of the factory process, thereby onlyleaving the product public key enabled.

When there is a subsequent need for re-customisation of a device aftercompletion of the production process, access to some or all of theproduction tools may be granted. However, when granting access tofactory tools after completion of the production process, it is ageneral problem to maintain the security of the system.

This problem is solved when the method further comprises the step ofloading a hash value of a secret data item into the key memory.Consequently, a re-customisation tool, preferably different and separatefrom the factory tools, may be provided, where the re-customisation toolknows the secret data item. Hence, a re-customisation of the device maybe performed in a controlled environment while maintaining the securityof the system and the distinction between production and post-productionprocesses/tools.

A re-customisation may, for example, comprise changing languagesettings, country-specific settings, or the like. Hence, are-customisation may, for example, be necessary when the customer wishesto deliver the device, e.g. as a part of another electronic equipment,to end-users of a different country, market, etc.

During the development of new electronic devices it is common toinitially produce a number of prototypes, for example to allow thirdparty providers to test software in connection with a new device. Insuch a situation it is desirable that the prototypes are also covered bythe security mechanisms of the production process. However, it isusually not desired that the subsequent product tools used for theactually released products are also usable for the prototypes, and viceversa.

Consequently, in a preferred embodiment the step of loading a productpublic key further comprises the step of loading a digital certificatecomprising the product public key, the digital certificate beingassociated with a validity period limiting the validity of the publickey, thereby limiting the validity of the prototype key to apredetermined validity period.

In another preferred embodiment, the step of loading a product publickey further comprises the step of loading a digital certificatecomprising the product public key; and the method further comprises thestep of subsequently invalidating the digital certificate by sending apredetermined message to the electronic equipment. Hence, it is anadvantage that no validity period needs to be predefined, thereby it ispossible to easily account for delays in the development and testingprocess of the prototypes. The message sent to the device may, forexample, be a message of a Short Message Service (SMS) or anothermessage service, or another secured indication to achieve deactivationvia an over-the-air transport mechanism.

In another embodiment, the product public key is selected from apredetermined set of customer public keys, thereby providing a mechanismfor differentiating different products, products from prototypes, and/ordifferent customers.

In one embodiment, the public keys are stored in relation with a digitalcertificate comprising the corresponding public key.

The invention further relates to an electronic device having storedtherein data that has been loaded into the electronic device byperforming the steps of the method described above and in the following.

The invention further relates to a method of re-customising anelectronic device having stored therein data that has been loaded intothe electronic device by performing the steps of the method describedabove and in the following, the method comprising the steps of

-   -   detecting whether a protectable identifier is set in the        electronic device;    -   obtaining the hash value of the secret data item from the key        memory;    -   comparing the obtained hash value with a reference hash value        calculated from a reference secret data item; and    -   if the protectable identifier is set and if the obtained hash        value corresponds to the calculated reference hash value,        initiating loading re-customisation data signed with the product        private key into the electronic device; otherwise aborting        re-customising the electronic device.

For the purpose of the present description, the step of detectingwhether the protectable identifier is set may comprise a detectionwhether the identifier has a predetermined value and/or other property.

The invention further relates to a system for re-customising anelectronic device having stored therein data that has been loaded intothe electronic device by performing the steps of the method describedabove and in the following, the system comprising a loader moduleadapted to perform the steps of the method of re-customising anelectronic device described above and in the following.

The invention further relates to a system for loading data into anelectronic device, the electronic device comprising a data memory forstoring data items and a key memory for storing at least onecryptographic key of a cryptographic public key mechanism, the systemcomprising

-   -   a first loader module for loading a factory public key into the        key memory;    -   a second loader module for loading factory software signed with        a factory private key corresponding to the factory public key        into the data memory;    -   a third loader module adapted to load into the key memory a        product public key different from the factory public key for        verifying subsequent data items to be loaded into the data        memory after delivering the electronic device to a customer, the        subsequent data items being signed with a corresponding product        private key; and to disable the factory public key prior to        delivering the electronic device to the customer.

The invention further relates to a computer program comprising codemeans adapted to perform the following steps in a method of loading datainto an electronic device, the device including a data memory forstoring data items and a key memory for storing at least onecryptographic key of a cryptographic public key mechanism:

-   -   loading into the key memory a product public key for verifying        subsequent data items to be loaded into the data memory after        delivering the electronic device to a customer, the subsequent        data items being signed with a corresponding product private        key; the product public key being different from a factory        public key stored in the key memory and used for verifying any        factory software to be loaded into the data memory and signed        with a factory private key corresponding to the factory public        key; and    -   disabling the factory public key prior to delivering the        electronic device to the customer.

The computer program may be embodied on a computer-readable medium suchas magnetic tape, optical disc, digital video disk (DVD), compact disc(CD or CD-ROM), mini-disc, hard disk, floppy disk, ferro-electricmemory, electrically erasable programmable read only memory (EEPROM),flash memory, EPROM, read only memory (ROM), static random access memory(SRAM), dynamic random access memory (DRAM), synchronous dynamic randomaccess memory (SDRAM), ferromagnetic memory, optical storage, chargecoupled devices, smart cards, PCMCIA card, etc.

According to a second aspect of the invention the above and otherobjects are achieved by a method of protecting an electronic device fromunauthorised reprogramming, the electronic device comprising a datamemory and a key memory, the method comprising loading into the keymemory a predetermined public key of a cryptographic public keymechanism for verifying subsequent data items to be loaded into the datamemory, the subsequent data items being signed with a correspondingprivate key; wherein the method further comprises setting a protectableidentifier in the electronic device, where the protectable identifieridentifies an entity authorised to reprogram the electronic device.

By setting a protectable identifier in the electronic device, theprotectable identifier identifying an entity authorized to reprogram theelectronic device, an unauthorised customer is prevented from loadingthe customer's own key into the key memory, which would then allow thecustomer to load the customers's own software. Hence, an increasedsecurity against unauthorised reprogramming of the device is achieved.

It is a further advantage of the invention that it provides acost-effective solution for a secure enabling of predetermined parts ofthe functionality of the electronic device, namely those functions thathave been licensed to the customer identified by the protectableidentifier.

When the protectable identifier further identifies a selected one of anumber of categories of public keys, the invention may be used todistinguish the production from the consumer product. This isadvantageous, since national regulations in some countries require thatproduction tools that can reprogram a (radio) device cannot run on aconsumer product. This can be achieved by using one public certificatefor production and another one for the consumer product and change tothe public certificate for the consumer product at the end of theproduction. By specifying the entity authorized to reprogram theelectronic device and the category of the certificate, a loader modulecan determine whether or not the loader module should function for agiven product, e.g. a given mobile phone.

Furthermore, when the protectable identifier identifies an entityauthorized to reprogram the electronic device and a selected one of anumber of categories of public keys, a mechanism is provided forsecurely recovering from a situation where the public key in theelectronic device has been destroyed or corrupted. Based on theinformation identified by the protectable identifier, a recovery modulecan determine which type of public key or certificate (e.g. productionor a consumer product certificate) to reload, thereby maintaining a highlevel of security even in error recovery situations.

In a preferred embodiment, the protectable identifier is written into aone-time programmable (OTP) area of a flash memory of the electronicdevice, thereby enabling a loader module that loads software into theelectronic device to uniquely determine the entity authorized toreprogram the electronic device, e.g. the authorized customer of thedevice. A small OTP memory for the protectable identifier ID on thecentral chip is preferable. In a preferred embodiment, the flash ID isbound to the used central chip by a suitable mechanism controlled by thecontrol chip, thereby further increasing the security, since the flashis prevented from being replaced by a differently programmed flash.

Hence, it is an advantage that only a limited amount of data is requiredto be stored in the OTP memory, thereby reducing the required size ofthe OTP memory and, thus, production costs. In particular, this is anadvantage, since the standard OTP memory sizes in current chipsetsprovide only 64-bit which is not sufficient for e.g. a publiccertificate. It is an advantage of the invention that it may beimplemented with standard chipsets. Furthermore, OTP solutions differbetween flash memory producers, and it is an advantage of the inventionthat it may be implemented with different types of OTP memory.

It is understood that, in some embodiments, a value derived from theprotectable identifier is stored instead of the identifier itself. Inparticular, in a preferred embodiment, a cryptographic hash valuederived from the protectable identifier is stored in the OTP memory,thereby providing an increased flexibility in the formatting of theprotectable identifier.

It is understood that the management of public keys and OTP settings ina mass production environment may be a complex task. Accordingly, afurther problem to be solved is how the security management should beorganised, in particular if the security management should encompass theproduction of the electronic device in a factory as well as theend-product at the customer and the product development organization,which may be a third party, e.g. a subcontractor.

In a preferred embodiment at least one of the transitions between statesin the security state diagram relate to a corresponding change in theprotectable identifier, thereby providing an effective mechanism for themanagement of the security requirements in a product life cycle.

When the protectable identifier is stored in an OTP memory that islockable by setting a lock flag, the status of said lock flag may beused as part of the identifier. For example, the lock status of an OTPor the IMEI of a mobile telephone may be used as a bit of information ofthe protectable identifier. For example the lock status may distinguisha device during production and an end-product.

The invention further relates to a method of loading data into anelectronic device protected according to the method described above andin the following, the method comprising the steps of

-   -   detecting whether the protectable identifier has a predetermined        property; and    -   if the protectable identifier has the predetermined property,        loading the data, the data being signed with the private key        corresponding to the public key stored in the device; otherwise        aborting loading the data.

For the purpose of the present description, the predetermined propertyof the identifier may correspond to the identifier fulfilling apredetermined condition, e.g. the identifier being different from apredetermined value, the identifier being equal to a predetermined valueor to one of a set or range of values, the identifier having apredetermined lock status, or the like.

The invention further relates to a system for loading data into anelectronic device protected according to the method described above andin the following, the system comprising a loader module adapted to

-   -   detect whether the protectable identifier has a predetermined        property; and    -   if the protectable identifier has the predetermined property, to        load the data, the data being signed with the private key        corresponding to the public key stored in the device; otherwise        to abort loading the data.

It is a further advantage of the invention that it provides a method forsecurely loading data into an electronic device that is suitable forhigh volume production processes.

It is a further advantage of the invention that no extra tools, such ashardlocks, smart cards, dongles, or the like, are required todifferentiate security relevant software/data load steps duringdifferent stages of the life cycle of a device, e.g. in the factory andoutside the factory, thereby simplifying the control and maintenance ofload tools.

In a preferred embodiment, the data memory and the key memory compriseselected blocks of a flash memory. Flash memory (sometimes also called“flash RAM”) is a type of nonvolatile memory that can be erased andreprogrammed in units of memory called blocks. It is a variation ofelectrically erasable programmable read-only memory (EEPROM) which,unlike flash memory, is erased and rewritten at the byte level, which isslower than flash memory updating. Flash memory is often used to holdcontrol code such as the basic input/output system (BIOS) in a personalcomputer. When data needs to be changed (rewritten) in flash memory, theflash memory can be written to in block (rather than byte) sizes, makingit easy to update. Flash memory gets its name because the microchip isorganized so that a section of memory cells are erased in a singleaction or “flash.” Flash memory is widely used in digital cellularphones, digital cameras, LAN switches, PC cards for notebook computers,digital set-up boxes, embedded controllers, and other electronicdevices.

Other examples of data memory and/or key memory include magnetic tape,optical disc, digital video disk (DVD), compact disc (CD or CD-ROM),mini-disc, hard disk, floppy disk, ferro-electric memory, electricallyerasable programmable read only memory (EEPROM), EPROM, read only memory(ROM), static random access memory (SRAM), dynamic random access memory(DRAM), synchronous dynamic random access memory (SDRAM), ferromagneticmemory, optical storage, charge coupled devices, smart cards, PCMCIAcard, etc.

Further preferred embodiments are disclosed in the dependant claims.

The present invention can be implemented in different ways including themethods described above and in the following, systems, electronicdevices, and further product means, each yielding one or more of thebenefits and advantages described in connection with the methodsmentioned above, and each having one or more preferred embodimentscorresponding to the preferred embodiments described in connection withthe methods mentioned above and disclosed in the dependant claims.

The invention will be explained more fully below in connection with apreferred embodiment and with reference to the drawing, in which:

FIG. 1 schematically illustrates a production process and are-customisation process according to an embodiment of the invention;

FIG. 2 shows a block diagram of a system for loading data into anelectronic device;

FIG. 3 shows a block diagram of an example of an electronic device;

FIG. 4 shows a block diagram of a system for loading software and datainto an electronic device and for customising an electronic deviceduring the production process;

FIGS. 5 a-b show block diagrams of embodiments of a system forre-customising an electronic device;

FIG. 6 shows a block diagram of a system for managing cryptographic keysand certificates;

FIGS. 7 a-d illustrate examples of production processes according tocorresponding embodiments of the invention;

FIG. 8 illustrates the structure of an embodiment of a protectableidentifier; and

FIG. 9 illustrates a security state diagram.

In the drawings, like reference signs refer to similar or correspondingcomponents, steps, etc.

FIG. 1 schematically illustrates a production process and are-customisation process according to an embodiment of the invention. Inan initial step S1 of the production process an electronic device 101 isprovided. In this embodiment, it is assumed that the electronic deviceincludes a mounted board, i.e. during the production of a product for acustomer, the described process may typically take place aftercompletion of the surface mounting of electronic components on a boardand before or during a final assembly step. The electronic devicecomprises a memory 102 including memory sections 103, 104 and 105. Thememory 102 may include one or more different types of memory and/or oneor more memory modules, such as EEPROM, Flash memory, on-chip memory,RAM, OTP memory, etc. The memory sections 103 and 105 may be addressableareas of a memory, such as flash memory. In a preferred embodiment, thememory section 104 is an OTP memory. In on embodiment, the memory 102 isa flash memory component including an OTP section.

During a first loading step a first factory loading tool 106 is used toload a factory public key PuK_(F) into memory section 105. The loadingtool 106 comprises memory 107 for storing the public key PuK_(F).

Within the field of cryptography, the use of combined public and privatekeys as such is known as public-key or asymmetric cryptography. A systemfor using public keys is called a public key infrastructure (PKI). Thevery nature of public-key cryptography permits a form of digital messagesigning. A sender may publish a decryption key, i.e. the public key, andkeeps a corresponding encryption key, i.e. the private key, secret. Whenthe sender encrypts a message or a value derived from the message,anyone can decrypt it using the public decrypting key and, in doing so,the recipient can be sure that the message could only have beenencrypted by the sender, since the sender is the sole possessor of theencryption key. Hence, the sender has effectively “signed” the message.Examples of public-key mechanisms include the RSA Cryptosystem (see e.g.Rivest, R., Shamir, A. and Adleman, L. “A method for obtaining digitalsignatures and public key cryptosystems.” Communications of the ACM, 21(1978), pp. 120-126) the EIGamal Cryptosystem (see e.g. EIGamal, T. “Apublic key cryptosystem and a signature scheme based on discretelogarithms.” IEEE Transactions on Information Theory, 31 (1985), pp.469-472) and elliptic curve cryptosystems (see e.g. Saeki, M., EllipticCurve Cryptosystems. M.Sc. Thesis, McGill University School of ComputerScience. 1996.).

Preferably, the public key is related to a digital certificate of thekey issuer/owner, e.g. in the case of the factory public key of themanufacturer. Here the term digital certificate refers to a data itemthat serves to validate the senders authorization. The data itemcomprises an identification of the certificate holder and the holderspublic key and, preferably, a digital signature of a certificationauthority for authentication. The certification authority attests thatthe sender's identifier is the one associated with the public key in thedata item. In the art, different types of public key certificates areknown as parts of a public key infrastructure that deals with digitallysigned documents, public key encryption, trusted third parties, andmechanisms for certificate publication and issuing, see e.g. the X509standard (ITU-T Recommendation X.509 (1997), “InformationTechnology—Open Systems Interconnection—The Directory: AuthenticationFramework”). Hence, throughout the present description, the public keysare also referred to as (public) certificates, e.g. the factory publickey will also be referred to as factory certificate. A compact format ofa digital certificate will be described below. Hence, a digitalcertificate may be regarded as representing a binding between a publickey and an entity, where the binding is certified by a signature from atrusted certification authority.

Preferably, prior to loading the factory certificate, the loading tool106 attempts to read a valid factory certificate or a correspondingcustomer certificate, which will be described below, from memory section105 and a predetermined protectable identifier from the OTP memorysection 104. If no valid certificate can be read from memory section 105and no protectable identifier can be read from OTP section 104, theloading tool loads the public key PuK_(F), thereby ensuring that theelectronic device has not previously undergone the factory process. Itis understood that the detection of the absence of a protectableidentifier may correspond to the detection of a default value of theidentifier, e.g. ID=‘0’, or the detection of a predetermined property ofthe identifier, e.g. the detection of a predetermined lock status, e.g.LockStatus=‘unlocked’. A embodiment of a format of a protectableidentifier will be described below.

The loading tool 106 may further be used for other settings such as thedownloading of calibration data, the setting of secure data areas bycalculating a cryptographic hash over the area, or the like.

Once the factory certificate is successfully loaded, the electronicdevice 101 enters the secured factory production process 125.

It is noted that the step of loading the factory certificate may beperformed in a pre-flash step prior to mounting the flash memory ontothe main board of the electronic device.

During step S2 of the secure factory process 125, the electronic device101 is tested and, if necessary, tuned, calibrated, or the like. Forexample, during production of a mobile telephone, the radio componentsmay require tuning and calibration, the mounted electronic componentsmay need to be tested, etc. For this purpose, factory software fortesting, calibration, etc. is loaded into the memory 102 of theelectronic device 101. The factory loading tool 108 for loading thefactory software comprises memory 109 and 110 for storing the factorysoftware and a factory private key PrK_(F) 110, 113, 117, respectively.The factory private key PrK_(F) 110, 113, 117 corresponds to the factorypublic key PuKF and is used by the loader 108 to sign the factorysoftware prior to loading the factory software into the electronicdevice 101.

Prior to loading the signed factory software into the electronic device101, the loading tool 108 attempts to detect a predetermined protectableidentifier in the OTP section 104 of the electronic device. If noprotectable identifier can be read from OTP section 104, the loadingtool 108 loads the factory software, thereby ensuring that theelectronic device has not previously undergone the factory process.Furthermore, the factory software is only accepted for loading andexecution by the electronic device, if the electronic devicesuccessfully verifies the received software using the factorycertificate PuK_(F). Additionally or alternatively, other softwareand/or data may be loaded into the electronic device at this stage, forexample an operating system and/or application software for use with thefinal product. The loading of this other software and/or data isperformed as described above by loading tool 108 or a separate loadingtool (not shown), where the software and/or date to be loaded is signedwith the factory private key PrK_(F) 110, 113, 117.

After successful testing of the electronic components, loading ofapplication software, or the like, the electronic device is customisedduring step S3, i.e. the device is given a specific “identity”. Forexample, this customisation step may be performed after the finalphysical assembly of the electronic device. During this step, softwarecustomisations are performed, such as loading of customer-specificsoftware, country adaptations, etc. Furthermore, in the context ofmobile terminals a number of known codes may be loaded, such as anunlock code, and IMEI, a customer code, etc. A customisation tool 111performs the above customisation, e.g. by loading software and/or data,such as codes, and/or by performing other settings in the electronicdevice. According to the invention, the customisation loader signs anydata or software to be loaded into the electronic device with thefactory private key PrK_(F) stored in a section 117 of the memory of thecustomisation tool. Furthermore, prior to performing the abovecustomisations, the customisation tool 111 verifies that no identifieris set in the OTP memory section 104 of the electronic device. Hence, asdescribed in connection with the previous step S2, a customisation bycustomisation tool 111 requires that the electronic device has a validfactory certificate stored in memory section 105 and that no protectableidentifier is set in OTP section 104. In a preferred embodiment, theelectronic device has associated with it an IMEI and the protectableidentifier is a combination of the IMEI and a customer ID stored in OTPmemory. As an IMEI may comprise approx. 15 characters, a combination ofthe IMEI with a short OTP customer ID, e.g. a 16 bit ID, provides aunique identification of the device and, at the same time, is protectedagainst removal. Furthermore, the OTP memory usage of this embodiment issmall.

Furthermore, during customisation step S3, a protectable identifier 112is set in OTP memory section 104 of the electronic device and theidentifier is protected against removal and modification, e.g. protectedby setting a lock flag in the OTP memory. The loading of the IDindicates the completion of the secure production process. Since theprevious loaders 106, 108, and 111 all require that no ID is set in theOTP section 104, it is ensured that the above factory tools cannot beapplied to a device which has completed the production process.

At the end of the factory production process, a final loading step S4 isperformed by a loading tool 114. The loading tool 114 verifies that avalid ID is set in the OTP section 104, thereby ensuring that theelectronic device has completed the production process. The loader 114loads a hash value H(S) of a secret value S into a memory section 103 ofthe electronic device. Preferably, the size of the hash value is atleast 64 bits in order to ensure a suitable security. With current andnon-distant state-of-the-art cryptoanalysis tools, 128 bits may be used.It is noted that the security is increased, if the secret value S isselected individually for every device, and if the calculation of thehash value is device-dependant, e.g. parameterised by a deviceidentifier. It is further noted that, in some embodiments, the hashvalue of the secret value S may be comprised of several hash values. Thehash value allows a subsequent secure re-customisation of the electronicdevice without re-entering the above secure production process. Theloading tool may retrieve the secret value S from a memory section 116of the loading tool 114 and calculate the corresponding hash value.Alternatively, the loading tool 114 may retrieve the secret value or thecalculated hash value from another computer. Preferably, the hash valueis signed with the factory private key PrK_(F) 110, 113, 117. Finally,the loader 114 loads a product public key PuK_(P) 115 into the memorysection 105 of the electronic device, thereby disabling the previousfactory certificate PuK_(F) 110, 113, 117. Alternatively, the productpublic key may be loaded into a different memory section and the factorycertificate may be disabled, e.g. by setting all or a predeterminedsubsets of its bits to zero.

Hence after completion of the production process, the electronic deviceincludes application software in its memory 102, a non-removable ID inthe OTP section 104, a hash value H(S) of a secret, and a product publickey PuK_(P).

At this stage, in steps S5 and S6, additional software and/or data 119may be loaded into the electronic device using a product loading tool118 having stored a product private key PrK_(P) (120) corresponding tothe product public key PuK_(P) 115.

Hence, authorized product software/data signed with the product privatekey PrK_(P) (120) is accepted by the electronic device. However, at thisstage, any software/data signed with the factory private key PrK_(F)110, 113, 117 will be rejected by the electronic device. Consequently, astrict division of the production process 125 and the post-productionprocess 126 is enforced, thereby ensuring that factory software orapplication software cannot be loaded by an unauthorized entity into anelectronic device. Likewise any software/data signed with the productprivate key PrK_(F) 110, 113, 117 of another customer, i.e. a privatekey that does not correspond to the public key stored in the device,will be rejected by the electronic device. Consequently, a customercannot load the customer's own software into a device authorised foranother customer. Furthermore, this ensures that tools of one customerdo not work on devices of another customer.

However, it may be necessary to re-customise some of the settingsperformed during the production process or to perform other kinds ofre-work, such as re-loading calibration software, or the like. Withinthe above described mechanism, the factory public key PuK_(F) cannot bere-loaded, since the loader 106 requires that no OTP ID is set in memorysection 104 of the electronic device. Furthermore, allowing such are-loading of the factory public key would involve the risk of misuse.

According to the invention, a re-customisation may be performed using aspecial re-customisation tool 121 which has access to the secret S (122)and the product private key PrK_(P) (123). The re-customisation toolverifies that a valid ID is set in OTP section 104. Furthermore, there-customisation requires that a hash value calculated from the secret Sin the customisation tool corresponds to the hash value H(S) stored inthe electronic device. This may be verified by the customisation tool orby the electronic device. Finally, any data/software sent to theelectronic device during re-customisation is signed with the productprivate key PrK_(P), thereby providing a secure re-customisation processwhich avoids a re-entering into the secure factory process 125, therebyenforcing a strict division between production process andpost-production process.

The above public and private keys may be keys of any suitable public keymechanism, such as RSA or Elliptic Curve Cryptography (ECC). Themechanism for the factory and the product keys may be the same ordifferent mechanisms.

Furthermore, it is understood, that the data/software loaded into theelectronic device may be signed by the respective loading andcustomisation tools 108, 111, 114, 118, or 121, or it may be signed by aremote computer and the signed data/software may be communicated to thecorresponding loading or customisation tool which performs the actualloading.

It is understood that the software and/or data may be compressed beforeloading it into the electronic device in order to reduce the loadingtime. Furthermore, it is understood that the software and/or data may beencrypted using a suitable private or public key encryption mechanism,thereby further increasing the security of the production process.

The loading and customisation tools may be special hardware devices orcircuits, or they may be implemented as computer programs executed on adata processing system, such as a standard PC, or they may beimplemented as a combination thereof. Hence, within this document, theterms loading station and loading tool are used interchangeably.Furthermore, the cryptographic keys of the loading and customisationtools may be stored on a corresponding removable medium, such as a CDROM, a smart card, etc. For example, the keys and the cryptographicsigning software may be implemented on a smart card which may beremovably inserted in the loading tool.

It is understood that several modifications of the above process arepossible within the scope of the invention. For example, some of theabove tools may be combined in a single tool or the division offunctions of the tools may be divided between the different tools in adifferent manner. For example tools 108 and 111 may be combined to onetool or the tools 111 and 114 may be combined to a single tool.Furthermore, some of the loading steps may be performed in a differentorder. For example, the hash value H(S) may be loaded during a previousloading step, e.g. by customisation tool 111.

FIG. 2 shows a block diagram of a system for loading data into anelectronic device. The system comprises a loading station 201 and anelectronic device 205. The loading station comprises a storage medium204 for storing the payload data to be loaded into the electronic deviceand other data for use in the processing of the payload data, such ascryptographic keys, address information, etc. The loading stationfurther comprises a processing unit 203 which is adapted, e.g. bysoftware loaded from the storage medium 204, to process the payloaddata, e.g. compress and/or encrypt the payload data and/or divide itinto smaller segments, generate header data, etc. Furthermore, theprocessing unit is adapted to control the transmission of the data tothe mobile station 205. The processing unit 203 may comprise a general-or special-purpose programmable microprocessor, Digital Signal Processor(DSP), Application Specific Integrated Circuit (ASIC), ProgrammableLogic Array (PLA), Field Programmable Gate Array (FPGA), etc., or acombination thereof. The loading station further comprises acommunications unit 202 comprising circuitry and/or devices suitable forenabling the loading station to communicate data with the electronicdevice via a wired or wireless communications link 209 such as a directdata link, a communications network, or the like. Examples of suchcommunications units include a network interface, a network card, aradio transmitter/receiver, a Bluetooth transceiver, a serial port, aparallel port, an infrared port, an IrDa port, a cable modem, atelephone modem, an Integrated Services Digital Network (ISDN) adapter,a Digital Subscriber Line (DSL) adapter, a satellite transceiver, anEthernet adapter, or the like. Accordingly, the communications link 209may be a short-range wireless communications link using electromagneticwaves. Examples of such communications links include a Bluetoothconnection or another connection based on radio frequencies, infrared,microwave, or the like. The communications link may further be a wiredconnection, e.g. a serial connection, and USB connection, or the like.In yet another embodiment, the connection may be established via acommunications network, such as a local area network, a cellularnetwork, the Internet, or the like. The loading station 201 furthercomprises an interface 210 comprising circuitry and/or devices suitablefor enabling the loading station to communicate data with another dataprocessing system. Examples of such interfaces include the examplesmentioned in connection with the communications unit 202 above. Furtherexamples include a floppy disk drive, a CD drive, or the like, or anyother suitable circuitry or device enabling the loading station toreceive payload data to be loaded into the loading station, loadingtools or other software to be executed by the loading station,cryptographic data, etc. These data and software may be received via acommunications network, e.g. the Internet, or on a storage medium, suchas a CD, a floppy disk, a memory card, or the like. The data may bereceived from one or more servers as will be described below. Thereceived data or software is stored on the storage medium 204, possiblyafter a verification process and/or further processing. The loadingstation may be a conventional, suitably programmed computer, e.g. a PC,comprising a suitable communications interface.

The electronic device 205 comprises a corresponding communications unit206 comprising circuitry and/or devices suitable for enabling theelectronic device to communicate data with the loading station. Theelectronic device further comprises a processing unit 207, e.g. ageneral- or special-purpose programmable microprocessor, Digital SignalProcessor (DSP), Application Specific Integrated Circuit (ASIC),Programmable Logic Array (PLA), Field Programmable Gate Array (FPGA),etc., or a combination thereof. The processing unit 207 is adapted, e.g.by software loaded from the storage medium 208 of the electronic device,to receive data from the loading station, to analyse and verify anyheader information, and to load the actual payload data into the storagemedium 108. If applicable, the processing unit 107 is further adapted toprocess the payload data, e.g. uncompress or decrypt it.

FIG. 3 shows a block diagram of an example of an electronic device. Theelectronic device 205 comprises a processing unit 207, as describedabove, for controlling the functions of the electronic device. Theelectronic device further comprises a radio interface 305 with anantenna 306 for transmitting and receiving data to/from a wirelesscommunications network, e.g. a cellular network. The electronic devicefurther comprises a user interface 304, e.g. a display, such as an LCD,or the like, a keypad, or other input means, such as a touch screen, orthe like. The user interface may be used during the loading process, ifthe loading is combined with an interactive authentication/approvalprocedure which requires an input from the user, e.g. the entering of apassword, a PIN, or the like. The electronic device may further comprisea subscriber identity module (SIM) 307 including memory for storingsubscriber identity information, a telephone number, and other datarelated to a user's subscription with a cellular network operator. Theelectronic device further comprises a storage medium 208 which maycomprise a RAM section 303, a ROM section 302 and a section 301comprising flash memory. The payload data received from the electronicdevice may be loaded in the flash section and/or the RAM section of thememory. Alternatively or additionally, the storage medium of theelectronic device may comprise other types of memory, such as EPROM,EEPROM, or the like, or other types of storage media, such as opticaldisc, digital video disk (DVD), compact disc (CD or CD-ROM), mini-disc,hard disk, ferromagnetic memory, optical storage, charge coupleddevices, PCMCIA cards, etc. Correspondingly, the received data may beloaded in any of the alternative memory types and/or storage media. Inone embodiment of the invention, the data received from the loadingstation may be loaded into the memory of the SIM 307. Finally, theelectronic device comprises a communications unit 206 as describedabove, e.g. a Bluetooth transceiver, an IrDa port, an USB adapter, acable connector, or the like. Alternatively, the radio interface 305 maybe used to receive the data over the air via a cellular network. Forexample, the electronic device may be any portable radio communicationequipment, where the term portable radio communication equipmentincludes all equipment such as mobile telephones, pagers, communicators,i.e. electronic organisers, smart phones, personal digital assistants(PDAs), handheld computers, or the like. Another example of anelectronic device comprises a chipset for use in a mobile telephone oranother type of electronic equipment, where the chipset may comprise amemory component and a processor, e.g. as exemplified by blocks 207 and208. Optionally, the chipset may comprise one or more of the otherblocks shown in FIG. 3, e.g. the communications unit 206 and/or theradio interface 305.

FIG. 4 shows a block diagram of a system for loading software and datainto an electronic device and for customising an electronic deviceduring the production process. The system comprises a security server401 a factory loading station 402 and an electronic device 205. Thesecurity server 401 may be a personal computer, a work station, anetwork server, a web server, etc. The security server is connected to acomputer network 403, e.g. the Internet, a local area network, anintranet, an extranet, etc. The loading station 402 is a computer withaccess to the computer network 403 and adapted to execute a computerprogram for loading software/data onto the electronic device 205, e.g.as described in connection with FIG. 2.

The security server 401 is adapted to distribute computer programs andcorresponding updates via the computer network 403 to the loadingstation 402 and, similarly, to other loading stations (not shown), i.e.computer programs to be run on the respective loading stations forcustomising and loading software/data into the electronic device 205 andcorresponding other electronic devices (not shown). The security server401 further distributes computer programs and data to be downloaded intothe electronic devices by the loading stations and the security servermay further provide additional services such as news, information,customer specific services, etc. Alternatively or additionally, thesecurity server may distribute computer programs, data, etc., via anyother suitable means, e.g. on a computer-readable medium such as afloppy disk, a CD ROM, etc. However, a connection via a computer networkfacilitates the implementation of automatic update mechanisms, versioncontrol mechanisms, etc.

The loading station 402 is adapted to provide security services relatedto the customisation of the electronic device 205 and the loading ofsoftware/data into the device 205. The security functions may includethe generation of signatures based on the factory private key asdescribed above, the generation of the protectable identifier, e.g. inconnection with an IMEI, as described above. Further examples of suchsecurity services include security functions in connection with thecommunication between the loading station and the electronic device,such as calculation of checksums, cryptographic functions, compression,etc. In one embodiment where the electronic device includes a mobileterminal, the security functions may further comprise the generation andencryption of SIMlock codes or the like. The loading station furtherprovides functionality for customising the software to be loaded intothe electronic device, e.g. by providing language files,customer-specific software, games, etc.

FIGS. 5 a-b show block diagrams of embodiments of a system forre-customising an electronic device. As described in connection withFIG. 1, the factory tools do not work anymore, once the electronicdevice has left the production process, i.e. one the factory public keyhas been replaced by a product public key. Instead, a special tool isused for reloading customisation files by a customer if necessary.

FIG. 5 a shows a block diagram of an example of a system forre-customising an electronic device. The system comprises a securityserver 401 as described in connection with FIG. 4, a customer toolserver 501, a re-customisation station 502, a customer server 503, asignature server 504, and an electronic device 205 to be customised. There-customisation station 502 is a specially adapted loading stationwhich is connected to the electronic device 205 as described inconnection with FIG. 2. The customer tool server 501 may be a personalcomputer, a work station, a network server, a web server, etc. that isconnected to the computer network 403. The customer tool server 501receives computer programs, updates, etc. from the central security toolserver 401, and makes them available for the customer-ownedre-customisation tool 502. Hence, the re-customisation tool mayautomatically be updated from the customer tool server when connected toit.

The customer server 503 may be a fileserver in a computer network 505 ofthe customer, e.g. a local area network, and intranet, or the like.Alternatively, the customer server may be a web server providing accessvia the internet or another communications network. Any re-customisationfiles, e.g. comprising data, compiled computer programs, or the like,are stored in a predetermined location of the filesystem of the customerserver 503. The system further comprises a signature server 504connected to the computer network 505 and adapted to monitor the abovelocation for files which are not provided with a correspondingsignature. If such a file is found, the signature server 504 is adaptedto sign that file with the product private key and store the signed fileat the above or another predetermined location on the customer server503. Subsequently, the re-customisation station 502 retrieves the signedfile(s) from the customer-server and loads the file(s) into theelectronic device after performing the security checks as described inconnection with FIG. 1.

FIG. 5 b shows a block diagram of another example of a system forre-customising an electronic device. As the system of FIG. 5 a, thesystem of FIG. 5 b comprises a security server 401, a customer toolserver 501, a re-customisation station 502, a signature server 504, andan electronic device 205 to be customised. According to this example, aclient program is executed on the re-customisation station 502 whichsends the re-customisation file(s) directly to the signature server 504.After signing the file(s), the signature server 504 returns the file(s)to the re-customisation station 502 which subsequently loads the file(s)into the electronic device after performing the security checks asdescribed in connection with FIG. 1.

FIG. 6 shows a block diagram of a system for managing cryptographic keysand certificates. The system comprises a certificate management system601, a certificate warehouse system 602, a signature server 504, and aloading system 603. The certificate management system 601 may comprise asuitably programmed personal computer, a work station, a network server,a web server, etc. and is connected to the certificate warehouse system602 via a computer network, e.g. the Internet, a local area network, anintranet, an extranet, etc. The certificate management system 601 isadapted to authorise key signing, assign key identifiers to keys and tosign keys with a manufacturer root key of a hierarchical key structurein order to increase the security of the system.

The certificate warehouse system 602 may comprise a suitably programmedpersonal computer, a work station, a network server, a web server, etc.The certificate warehouse system 602 is adapted to generate pairs ofpublic and private keys according to a suitable public key mechanism.The customer certificate warehouse system 602 further requests anauthentication from the certificate management system and requests thegenerated public key to be signed with the manufacturer root key by thecertificate management system 601. The signed public key is stored inthe certificate warehouse system 602 and forwarded to the loading system603. The loading system 603 loads the public key into the electronicdevice.

For example, in connection with product keys, the loading system iscomprised in the production system for the electronic device and itloads the product public key at the end of the production process asdescribed in connection with FIG. 1. An example of an production systemwas described in connection with FIG. 4 above.

Similarly, the factory keys and/or prototype keys can be distributed bya system according to FIG. 6.

The generated private keys are stored in the customer certificatewarehouse system 602, preferably in encrypted form, and transported tothe signature server 504 via a secure channel.

FIGS. 7 a-d illustrate examples of production processes according tocorresponding embodiments of the invention.

In the example of FIG. 7 a, the loading steps are performed in the orderaccording to the example described in connection with FIG. 1 above, i.e.

Step S701: Load factory public key.

Step S702: Load factory software.

Step S703: Load protectable identifier.

Step S704: Load product public key.

Step S705: Disable factory public key.

In the example of FIG. 7 b, the protectable identifier is loaded at theend of the production process, i.e. the order of loading steps is

Step S701: Load factory public key.

Step S702: Load factory software.

Step S704: Load product public key.

Step S705: Disable factory public key.

Step S703: Load protectable identifier.

It is noted that in connection with the loading step S4 as described inconnection with FIG. 1, the loading of the product public key included averification that the protectable identifier was set. It is understoodthat in the example of FIG. 7 b, this verification is not applicable, asthe protectable identifier is set after the loading of the productpublic key. It is further understood that a corresponding considerationapplies to the following examples.

In the example of FIG. 7 c, the protectable identifier is loaded beforeloading the factory software, i.e. the order of loading steps is

Step S701: Load factory public key.

Step S703: Load protectable identifier.

Step S702: Load factory software.

Step S704: Load product public key.

Step S705: Disable factory public key.

In the example of FIG. 7 d, the protectable identifier is loaded beforeloading the factory software, i.e. the order of loading steps is

Step S703: Load protectable identifier.

Step S701: Load factory public key.

Step S702: Load factory software.

Step S704: Load product public key.

Step S705: Disable factory public key.

It is noted that in the above examples, alternatively, other orders ofloading steps may be employed. For example, the steps S704 and S705 maybe reversed, or combined in a single step, e.g. by overwriting thefactory public key with the product public key.

Hence, in the above a production process for an electronic device hasbeen disclosed which provides a high level of security.

It is understood that the production process according to the inventionmay be used in a number of different contexts. For example, it is acommon problem for manufacturers of electronic devices that anincreasing part of the software for the electronic devices is developedby third party companies. It is an advantage of the present inventionthat it provides a mechanism for controlling prototypes of an electronicdevice and ensuring that prototype software cannot run on a finalproduct.

In one embodiment, during the production of prototype devices, theproduct public key loaded into the device at the end of the productionprocess is a special public prototype key. Hence, a number of prototypesare produced having a public prototype key, thereby allowing a thirdparty software developer to load software signed with a correspondingprivate prototype key. The signing of the software may be performed bythe third party supplier or by the manufacturer. If there are more thanone third party software developers, a corresponding number of differentprototype key pairs may be used, thereby allowing the manufacturer todifferentiate between different third party suppliers. Hence, accordingto the invention, a third party software supplier has the possibility totest the software in a realistic environment while, at the same time,ensuring that the software cannot be directly loaded into the finalproduct, since the product devices are equipped with a product publickey different from the prototype keys. Hence, without knowledge of thecorresponding product private key, the third party supplier cannot loadits software into the product.

A prototype public key may be related to a corresponding certificate,thereby providing a possibility of imposing a time limit on the validityof the prototype key.

In another embodiment, the prototype keys may be activated and/ordeactivated by a command message sent to the electronic deviceover-the-air. For example, in the context of mobile terminals, a messageof a short message service (SMS) may be sent to the mobile terminal, themessage comprising a predetermined deactivation command and, preferably,a digital signature, e.g. in a message header. In the mobile terminal,the message is routed to a respective application which checks thesignature and deactivates the mobile terminal for use as a prototype,e.g. by disabling the public prototype key or in another suitablemanner.

Preferably, the digital signature corresponds to the prototype key inthe mobile terminal, thereby ensuring that only the owner of thecorresponding private prototype key may issue a valid deactivationmessage.

Furthermore, by using a time-stamp, e.g. included in the data to besigned, a re-use of a previously sent message can be prevented.

If the message includes a suitable device identifier, such as the IMEIof the mobile terminal, the message may be made specific for only onedevice.

FIG. 8 illustrates the structure of an embodiment of a protectableidentifier. The protectable identifier, generally designated 800,comprises four components that encode the information used for thesecurity management: a customer identifier (CID) 803, a product statemask (PSM) 804, an International Mobile Equipment Identity (IMEI) 805,and a lock status (OTPLS) 802. In the example of FIG. 8, the protectableidentifier comprises the contents of a 64-bit OTP memory section 801that encode the CID, the PSM, and the IMEI. The CID is encoded as 11bits, the PSM as a single bit, and the IMEI is encoded as a compactencoding of the standardized IMEI requiring 52 bits. The encoded IMEIwill be referred to as EIMEI. It is noted that the IMEI refers to aunique number given to every mobile telephone. IMEI numbers of cellularphones connected to a GSM network are stored in a database(EIR—Equipment Identity Register) containing all valid mobile phoneequipment. When a phone is reported stolen or is not type approved, thenumber is marked invalid. The number comprises a type approval code(TAC), a country code, an assembly code, a manufacturer identifier, anda serial number. The IMEI is an 18-byte identifier of the formdddddd-dd-dddddd-d where d ε{0,1,2, . . . ,9}. For example, the IMEI canbe encoded by encoding the two 6 digit groups into a binaryrepresentation and the remaining three digits as binary encoded hexdigits. This requires 52 bits (20+8+20+4). Assuming that all digits canoccur the minimal encoding of the IMEI requires 50 bits. Hence the abovecoding is only two bits longer than the minimal value. Since the longestpart is only 20 bits long the above coding is easily implemented onstandard 32-bit processors used in mobile devices.

The lock flag is encoded by the lock mechanism provided by the OTPmemory used. For example, in one embodiment the OTP memory section of aflash memory may be locked by writing, via a predetermined irreversiblecommand of the flash memory, a predetermined value into a lock bit,indicating that the OTP memory section is locked.

It is understood that the above parameters may be encoded by alternativerepresentations. The 64 bit encoding of FIG. 8 is advantageous as manystate-of-the art flash memories (regarded as a component) have a 64-bituser programmable OTP area outside the normal address space of thememory. This allows the realization of the management system at noadditional hardware costs for the flash memories. For example, in analternative embodiment, the IMEI may be encoded as 15 binary encoded hexdigits (thus omitting the three markers (“-”) having fixed positions).This requires 60 bits for storage.

FIG. 9 illustrates a security state diagram. The security state diagramgenerally designated 900 comprises security states of a life cyclecomprising a production state 901, a product development or R&D state902 and a consumer product state 903, and the transitions between them.It is understood that, in alternative embodiments, the security statediagram may include additional and/or alternative states. For example,by differentiating between different R&D centres, such as differentthird party development centres, each of these centres could use specialmobile phones during development, if each centre uses its owncertificate in the mobile phones.

The states of the state diagram are associated with respective values ofthe protectable identifier and with respective certificate categories.In the following a compact format of a digital certificate includingcertificate category information is described.

Standard certificates, e.g. certificates according to the X509 V3standard, allow the signer (the issuer) of the certificate to bind (bymeans of so-called extensions) the public key to additional informationthat describes what purpose the public key can be used for whenpresenting the certificate. However, the encoding of these certificatesis complex because of the many fields that have to be present and thespecial encoding via the ISO ASN.1 DER/BER encoding rules. The softwareneeded for parsing the certificates is complex and requires tens ofkilobytes code when implemented. Such code sizes are typically too largefor software that has to be ROMed into the controller chip of e.g. amobile telephone or the like.

Since, according to the methods described herein, the certificates areused in the limited context of SW signing for a certain class ofproducts, the certificate format of X509 is not only complex it is alsoinefficient for the specific purpose. The above disadvantages areremedied by using a compact certificate format, e.g. the formatexemplified in the following table:

ITEM DESCRIPTION Version no certificate format version number CID_O CIDof certificate owner CID_I CID of certificate issuer Depth depth incertificate chain Valid Until expiry date of certificate Signed Datedate of signing ISM index of signing method PKUC public key usagecategory, indicating the category of the digital certificate PKDATA thepublic key SIGN digital signature (according to the signing methodindicated by ISM).

In a preferred embodiment, the binary encoding of certificates is donesuch that its fields are easily parsed by an application, e.g. in Java,without many conversions. Here it is advantageous, albeit less compact,to have many fields represented as (binary) 32 bit integers.

Hence, the above format provides an efficient and compact certificateformat.

The usage limitations of the public key when presenting the certificateare efficiently handled by encoding of usage category codes that areassigned to the distinct usage environments. In the following, for thesake of simplicity of the description, each usage category will beassociated with a colour. It is understood, however, that in a practicalimplementation the usage categories are encoded digitally, e.g. asdescribed above. For example, for the purpose of the presentdescription, the factory environment can be assigned color “White”, theR&D (development) environment color “Purple”, and the end-user (finalproduct) environment color “Yellow”.

Hence, in the state diagram 900, each of the states 901, 902, and 903corresponds to a different category of public certificates, eachcategory being labelled by a “color”: State 901 corresponds to a “white”certificate, state 902 corresponds to a “purple” certificate, and state903 corresponds to a “yellow” certificate.

The states are encoded by the protectable identifier. In one embodiment,where the permanent identifier is encoded as described in connectionwith FIG. 8, the three states of the state diagram are encoded asfollows:

-   -   Factory state 901: The OTP is unlocked. Furthermore, the        electronic device comprises no valid certificate or a factory        (“white”) certificate.    -   R&D state 902: The OTP is locked and comprises a customer ID        and/or an encoded IMEI (optionally a test IMEI), and the product        state mask is set to PSM=O.    -   Product state 903: The OPT is locked and comprises a customer        identifier (CID), an encoded IMEI, and the product state mask is        set to 1. Furthermore, the electronic device comprises a valid        product (“yellow”) certificate.

Hence, in one embodiment, the protectable identifier is indicative ofthe customer ID and the category (“color”) of the certificate, i.e. thecorresponding state of the security state diagram. In particular, thecategory of the certificate can be derived from a combination of thefields of the protectable identifier.

It is noted that, in some embodiments, alternative or additional statecodes may be used. For example, in connection with devices that are onlyused in the R&D environment, e.g. early prototypes, an all-zero OTPvalue (OTP=“000 . . . 00”) may be used as a possible code in associationwith non-product states, i.e. states 901 and 902. In this embodiment,the factory and the R&D states can be distinguished by means of thecategory (“color”) of the certificate. The current OTP memories have theproperty that the OTP bits are initially (i.e. when the OTP memory isdelivered for use in a device) all in the “1” position. As long theOTPLS is unlocked it is possible to write a zero (“0”) into a “1”position. However, the reverse process, i.e. writing a “1” into aposition that was previously set to “0”, is not possible. Hence, oncebeing brought into the all zero state, the OTP bits cannot be changed.However, it is understood that other OTP technology could result in adifferent preferred coding. For example, an alternative OTP may have asimilar behaviour but allowing only transitions from 0's to 1's. Hence,by using the all zero OTP value and associating it with the non-productenvironment one obtains a robust state definition when experimentingwith the device hardware in the R&D environment. Furthermore, one stillcan secure a clear distinction between the R&D and product state(environment) as needed by the reprogramming tools to tell the states ofthe device apart and prevent unauthorized state transitions.

The transitions between the states 901, 902, and 903 are markedrespective arrows: Arrow 912 corresponds to a transition from theproduction state 901 to the R&D state 902, arrow 921 corresponds to atransition from the R&D state 902 to the production state 901, arrow 913corresponds to a transition from the production state 901 to theend-product state 903, arrow 931 corresponds to a transition from theend-product state 903 to the production state 901, arrow 923 correspondsto a transition from the R&D state 902 to the end-product state 903, andarrow 932 corresponds to a transition from the end-product state 903 tothe R&D state 902. In order to ensure the security, not all of the abovetransitions are allowed. In the example of FIG. 9, only the transitions912 and 913 are allowed, while the remaining transitions are forbiddentransitions as indicated by the dashed arrows. Hence, in thisembodiment, only the factory is allowed to change a certificate.

Each transition between states corresponds to a change in the parametersof the protectable identifier. For example,

-   -   Transition 912 is indicated by the storing of a CID and/or a        test IMEI into the OTP, and by locking the OTP.    -   Transition 913 is indicated by storing a CID and/or a product        IMEI into the OTP and by setting the product state mask to        PSM=1.

Hence, a software loader module can exploit the coding of the states inthe life cycle state diagram in order to make a distinction between thestates. In one embodiment, a software loader module is configured toonly execute, if the CID in the OTP is valid. When the loader module isfurther configured to only accept software that can be verified with acertificate installed in the electronic device, and when the boot ROM ofthe electronic device only accepts a loader that can be verified with aninstalled certificate, an efficient and security binding betweenhardware and software is provided.

Furthermore, recovery loaders can exploit the coding of the states inthe life cycle state diagram in order to recover a state of the statediagram, e.g. after the loaded data has been corrupted. In FIG. 9, thisis indicated by arrows 911, 922, and 933. For example, an embodiment ofa recovery process for recovering a corrupted public key may beperformed as follows: Initially, a recovery loader program is loadedinto the device. Subsequently, the recovery loader determines whether avalid public key is stored in the key memory of the device. If such akey is detected, the recovery process is terminated. Otherwise, therecovery loader determines the state of the life cycle state diagram bydetecting the OTP settings, e.g. the product state mask etc. describedabove, and loads the public key corresponding to the detected state.

Hence, in the above a method and means are disclosed to securely handledevice reprogramming capabilities during the different stages of thedevice from factory to R&D and final end-user product.

It is noted that the features of the methods described above may beimplemented in software and carried out in a data processing system orother processing means caused by the execution of computer-executableinstructions. The instructions may be program code means loaded in amemory, such as a RAM, from a storage medium or from another computervia a computer network. Alternatively, the described features may beimplemented by hardwired circuitry instead of software or in combinationwith software.

It is noted that the term “electronic device” is intended to compriseany device comprising processing means and a memory. The term processingmeans comprises general- or special-purpose programmablemicroprocessors, Digital Signal Processors (DSP), Application SpecificIntegrated Circuits (ASIC), Programmable Logic Arrays (PLA), FieldProgrammable Gate Arrays (FPGA), special purpose electronic circuits,etc., or a combination thereof.

Examples of such electronic devices include computers, such asstationary and portable PCs, stationary and portable radiocommunications equipment, etc., and in particular components thereof,such as processing units, chip sets or the like. The term portable radiocommunications equipment includes mobile radio terminals such as mobiletelephones, pagers, communicators, e.g. electronic organisers, smartphones, personal digital assistants (PDAs), or the like.

It is further noted that the term “loader module” is intended tocomprise any device or circuitry adapted to load data and/or softwareinto the electronic device. The device may comprise a suitablyprogrammed processor and an interface for loading the data/software ontothe electronic device. Furthermore, the loader module may be implementedas a computer program or a component of a computer program adapted to beexecuted on a data processing system having communication circuitryadapted to communicate with the electronic device via a datacommunications link.

It is further noted that the term “hash value” is intended to refer to aone-way representation of the secret data item, i.e. a representation inwhich it is computationally infeasible to deduce the secret data itemfrom the representation and where two different secret data items yieldtwo different representations.

It is further noted that the term “factory software” is intended tocomprise any computer-executable instructions loaded into the electronicdevice during production. The factory software may be executed duringproduction, e.g. for testing of hardware components, calibration ofcomponents, e.g. the radio circuit of a mobile telephone, setting ofparameters, customisation, etc. Alternatively or additionally, thefactory software may comprise instructions to be executed aftercompletion of the production, e.g. pre-installed operating systems, etc.Hence, the factory software may be loaded permanently or temporarilyinto the electronic device.

1. A method of loading data into an electronic device, the electronicdevice comprising a data memory for storing data items and a key memoryfor storing at least one cryptographic key of a cryptographic public keymechanism, the method comprising: loading a factory public key (PuK_(F))into the key memory; loading factory software signed with a factoryprivate key (PrK_(F)) corresponding to the factory public key into thedata memory; loading into the key memory a product public key (PuK_(P))different from the factory public key for verifying subsequent dataitems to be loaded into the data memory after delivering the electronicdevice to a customer, the subsequent data items being signed with acorresponding product private key (PrK_(P)); and disabling the factorypublic key (PuK_(F)) prior to delivering the electronic device to thecustomer, wherein the loading of the product public key (PuK_(P)) causesthe factory public key (PuK_(F)) to be disabled.
 2. The method accordingto claim 1, wherein the method further comprises the step of setting aprotectable identifier in the electronic device indicative of acompletion of a production process.
 3. The method according to claim 2,wherein the step of loading the factory public key comprises the stepsof: detecting whether the protectable identifier is set; if theprotectable identifier is set, aborting the step of loading the factorypublic key; otherwise loading the factory public key.
 4. The methodaccording to claim 2, wherein the step of loading the product public keycomprises the steps of: detecting whether the protectable identifier isset; if the protectable identifier is set, loading the product publickey; otherwise aborting the step of loading the product public key. 5.The method according to claim 2 wherein such steps are performed in amobile telephone having associated with it an International MobileEquipment Identity; and the protectable identifier comprises theInternational Mobile Equipment Identity and a further identifier storedin a one time programmable arrangement.
 6. The method according to claim1 wherein such steps are performed in a mobile telephone.
 7. The methodaccording to claim 1 wherein the steps performed in the data memory andthe key memory occur in selected blocks of a flash memory.
 8. The methodaccording to claim 1 wherein the method further comprises the step ofloading a hash value of a secret data item into the key memory.
 9. Themethod according to claim 8, wherein the secret data item is selectedindividually for each electronic device.
 10. The method according toclaim 8 wherein the hash value is determined by a method that depends onthe electronic device.
 11. The method according to claim 1 wherein thestep of loading a product public key further comprises the step ofloading a digital certificate comprising the product public key, thedigital certificate being associated with a validity period limiting thevalidity of the public key.
 12. The method according to claim 1 whereinthe step of loading a product public key further comprises the step ofloading a digital certificate comprising the product public key; and themethod further comprises the step of subsequently invalidating thedigital certificate by sending a predetermined message to the electronicequipment.
 13. The method according to claim 1 wherein the productpublic key is selected from a predetermined set of customer public keys.14. The method according to claim 13, wherein the set of customer publickeys comprises a prototype public key for use with prototypes of theelectronic device.
 15. A method of re-customizing an electronic device,the method comprising the steps of: detecting whether a protectableidentifier is set in the electronic device; obtaining the hash value ofthe secret data item from the key memory; comparing the obtained hashvalue with a reference hash value calculated from a reference secretdata item; and if the protectable identifier is set and if the obtainedhash value corresponds to the calculated reference hash value,initiating loading re-customization data signed with a product privatekey (PrK_(P)) into the electronic device; otherwise abortingre-customizing the electronic device; loading a factory public key(PuK_(F)) into the key memory; loading a factory software signed with afactory private key (PrK_(F)) corresponding to the factory public key(PuK_(F)) into the data memory; loading a product public key (PuK_(P))different from the factory public key (PuK_(F)) for verifying subsequentdata items to be loaded into the data memory after delivering theelectronic device to a customer into the key memory, the subsequent dataitems being signed with the corresponding product private key (PrK_(P));and disabling the factory public key (PuK_(F)) prior to delivering theelectronic device to the customer, wherein the loading of product publickey (PuK_(P)) caused the factory public key (PuK_(F)) to be disabled.16. A system for storing data into an electronic device, the electronicdevice comprising a data memory for storing data items and a key memoryfor storing at least one cryptographic key of a cryptographic public keymechanism, the system comprising: a first loader module for loading afactory public key (PuK_(F)) into the key memory; a second loader modulefor loading factory software signed with a factory private key (PrK_(F))corresponding to the factory public key (PuK_(F)) into the data memory;wherein the system further comprises a third loader module adapted: toload into the key memory a product public key different from the factorypublic key (PuK_(F)) for verifying subsequent data items to be loadedinto the data memory after delivering the electronic device to acustomer, the subsequent data items being signed with a correspondingproduct private key (PrK_(P)); and to disable the factory public key(PuK_(F)) prior to delivering the electronic device to the customer,wherein the loading of the product public key (PuK_(P)) causes thefactory public key (PuK_(F)) to be disabled.
 17. A system forre-customizing an electronic device having stored therein data that hasbeen loaded into the electronic device, the system having a loadermodule comprising: means to detect whether a protectable identifier isset in the electronic device; means to obtain the hash value of thesecret data item from the key memory; means to compare the obtained hashvalue with a reference hash value calculated from a reference secretdata item; and if the protectable identifier is set and if the obtainedhash value corresponds to the calculated reference hash value; means toinitiate loading re-customization data signed with the product privatekey (PrK_(P)) into the electronic device; otherwise to abortre-customizing the electronic device; means for loading a factory publickey (PuK_(F)) into the key memory; means for loading a factory softwaresigned with a factory private key (PrK_(F)) corresponding to the factorypublic key (PuK_(F)) into the data memory; means for loading a productpublic key (PuK_(P)) different from the factory public key (PuK_(F)) forverifying subsequent data items to be loaded into the data memory afterdelivering the electronic device to a customer into the key memory, thesubsequent data items being signed with the corresponding productprivate key (PrK_(P)); and means for disabling the factory public key(PuK_(F)) prior to delivering the electronic device to the customer,wherein the loading of product public key (PuK_(P)) caused the factorypublic key (PuK_(F)) to be disabled.
 18. An electronic devicecomprising: a data memory for storing data items a key memory forstoring at least one cryptographic key of a cryptographic public keymechanism, means for receiving a factory public key (PuK_(F)) into thekey memory; means for receiving factory software signed with a factory aprivate key (PrK_(F)) corresponding to the factory public key (PuK_(F))loaded into the data memory, means for verifying subsequent data itemsto be loaded into the data memory after delivering the electronic deviceto a customer using a product public key (PuK_(P)) different from thefactory public key (PuK_(F)), wherein the subsequent data items aresigned with a corresponding product private key (PrK_(P)) and thefactory public key (PuK_(F)) is disabled prior to delivering theelectronic device to the customer, wherein the loading of product publickey (PuK_(P)) causes the factory public key (PuK_(F)) to be disabled.19. A computer program comprising code means embodied on a computerreadable medium and adapted to be executed by a processor operable toperform the steps of: storing data into an electronic device including adata memory for storing data items and a key memory for storing at leastone cryptographic key of a cryptographic public key mechanism; loadinginto the key memory a product public key (PuK_(P)) for verifyingsubsequent data items to be loaded into the data memory after deliveringthe electronic device to a customer, the subsequent data items beingsigned with a corresponding product private key (PrK_(P)); the productpublic key (PuK_(P)) being different from a factory public key (PuK_(F))stored in the key memory and used for verifying any factory software tobe loaded into the data memory and signed with a factory private key(PrK_(F)) corresponding to the factory public key (PuK_(F)); anddisabling the factory public key (PuK_(F)) prior to delivering theelectronic device to the customer, wherein the loading of the productpublic key (PuK_(P)) causes the factory public key (PuK_(F)) to bedisabled.
 20. A method of protecting an electronic device having a datamemory and a key memory, from unauthorized reprogramming, the methodcomprising the steps of: loading a factory public key (PuK_(F)) into thekey memory; loading factory software signed with a factory private key(PrK_(F)) corresponding to the factory public key into the data memory;loading into the key memory a product public key (PuK_(P)) differentfrom the factory public key (PuK_(F)) for verifying subsequent dataitems to be loaded into the data memory after delivering the electronicdevice to a customer, the subsequent data items being signed with acorresponding product private key (PrK_(P)); setting a protectableidentifier in the electronic device, where the protectable identifieridentifies an entity authorized to reprogram the electronic device; anddisabling the factory public key (PuK_(F)) prior to delivering theelectronic device to the customer, wherein the loading of the productpublic key (PuK_(P)) causes the factory public key (PuK_(F)) to bedisabled.
 21. The method according to claim 20, wherein the protectableidentifier identifies a selected one of a number of categories of publickeys.
 22. The method according to claim 20, wherein the protectableidentifier is indicative of a selected one of a number of stages in thelife cycle of the electronic device.
 23. The method according to claim20, wherein the protectable identifier identifies a state in a securitystate diagram, each state representing a stage in the life cycle of theelectronic device.
 24. The method according to claim 23, wherein atleast one of the transitions between states in the security statediagram relate to a corresponding change in the protectable identifier.25. The method according to claim 20, wherein the protectable identifieris stored in a one time programmable (OTP) memory.
 26. The methodaccording to claim 25, wherein the protectable identifier comprises anidentifier identifying an entity authorized to reprogram the electronicdevice, a product state indicator, a lock status of the one timeprogrammable memory, and a product identifier identifying the electronicdevice.
 27. The method according to claim 20, wherein the public key iscomprised in a digital signature which is encoded to be directlyreadable from within Java.
 28. The method of loading data into anelectronic device protected according to the method of claim 20, themethod comprising the further steps of: detecting whether theprotectable identifier has a predetermined property; and if theprotectable identifier has said predetermined property, loading thedata, the data being signed with said private key; otherwise abortingloading the data.
 29. A system for protecting an electronic devicecomprising: a data memory in the electronic device for storing dataitems; and a key memory in the electronic device for storing at leastone cryptographic key of a cryptographic public key mechanism; means forloading a factory public key (PuK_(F)) into the key memory; means forloading factory software signed with a factory private key (PrKF)corresponding to the factory public key (PuK_(F)) into the data memory;means for loading into the key memory a product public key (PuK_(P))different from the factory public key (PuK_(F)) for verifying subsequentdata items to be loaded into the data memory after delivering theelectronic device to a customer, the subsequent data items being signedwith a corresponding product private key (PrK_(P)); and means fordisabling the factory public key (PuK_(F)) prior to delivering theelectronic device to the customer, wherein the loading of the productpublic key (PuK_(P)) causes the factory public key (PuK_(F)) to bedisabled.
 30. A system for loading data into an electronic device,comprising: the electronic device having a data memory, the data memoryadapted to store data items and a key memory for storing at least onecryptographic key of a cryptographic public key mechanism; theelectronic device adapted to receive a factory public key (PuK_(F)) intothe key memory and factory software signed with a factory private key(PrK_(F)) corresponding to the factory public key (PuK_(F)) into thedata memory; means for providing a product public key (PuK_(P))different from the factory public key (PuK_(F)) for verifying subsequentdata items to be loaded into the data memory of the electronic deviceafter delivering the electronic device to a customer; the subsequentdata items being signed with a corresponding product private key(PrK_(P)) wherein the loading of product public key (PuK_(P)) causes thefactory public key (PuK_(F)) to be disable prior to delivering theelectronic device to the customer; a means to set a protectableidentifier in the electronic device, where the protectable identifieridentifies an entity authorized to reprogram the electronic device; anda loader module adapted to detect whether the protectable identifier hasa predetermined property; and if the protectable identifier has saidpredetermined property, to load the data, the data being signed withsaid private key; otherwise to abort loading the data.